This application is related to the following co-pending U.S. Patent Applications:
U.S. patent application Ser. No. 09/483,123 entitled, A PROGRAM-DEVELOPMENT ENVIRONMENT FOR USE IN GENERATING APPLICATION PROGRAMS, filed Jan. 14, 2000;
U.S. patent application Ser. No. 09/483,759 entitled METHOD AND APPARATUS FOR DETECTING AND RESOLVING CIRCULAR FLOW PATHS IN GRAPHICAL PROGRAMMING SYSTEMS, filed Jan. 14, 2000;
U.S. patent application Ser. No. 09/483,122 entitled, REPEATING PROGRAM OBJECT FOR USE WITH A GRAPHICAL PROGRAM-DEVELOPMENT SYSTEM, filed Jan. 14, 2000; and
U.S. patent application Ser. No. 09/483,124 entitled, PROGRAM OBJECT FOR USE IN GENERATING APPLICATION PROGRAMS, filed Jan. 14, 2000.
1. Field of the Invention
The present invention relates generally to the field of computer programming and, more specifically, to software development environments.
2. Background Information
To generate a software program that can be executed or run by a computer, a software developer or programmer typically chooses a programming language, such as BASIC (Beginner""s All-purpose Symbolic Instruction Code), Fortran, C, etc., and writes source code using the keywords, syntax, variable names, data structures, etc. defined by the selected programming language. Each programming language typically defines its own unique syntax and keywords for performing various functions. After the source code has been written, it is typically converted by a compiler into a machine readable format that can be understood by the computer (e.g., object code). If the developer used incorrect keywords or syntax, the source code cannot by compiled successfully.
The source code is typically written with a text editor and organized into a series of lines of code. Although simple programs may only need a few lines of code, complex programs often consume hundreds, thousands or tens of thousands of lines of code. Significant portions of code, moreover, are often required just to generate displayable user interface images or forms, such as text boxes, command buttons, etc. that can be displayed by windows-based computer systems, such as personal computers running the Microsoft Windows(copyright) series of operating systems from Microsoft Corporation of Redmond, Wash. Furthermore, significant editing is often required to make even relatively minor adjustments to such user interface elements (e.g., moving, re-sizing, etc.).
In order to simplify the creation of such user interface images or forms, Microsoft developed and released a programming system known as Visual Basic(copyright). Visual Basic includes a language engine for executing text-based programming statements, and a forms layout package having a plurality of objects or icons representing common user interface elements, such as text boxes, radio buttons, command buttons, scroll bars, etc. When a developer selects one of these objects from a tool palette and places it onto a form window, Visual Basic automatically creates corresponding code to support that object. By eliminating the need to write code just to display conventional interface elements, Visual Basic greatly simplified the creation of programs to be run on Windows-based platforms. These objects are typically stored in one or more dynamic link libraries (DLLs) that are loaded and run as necessary at application run-time. Since Visual Basic is an xe2x80x9copenxe2x80x9d programming languages, meaning that its syntax and command structures are known and available, third-parties have created and marketed a whole range of objects that can be added to a Visual Basic forms window to facilitate the creation of all sorts of different application programs.
With the release of Visual Basic 4.0, Microsoft extended Visual Basic to support software constructs that have certain object-oriented features by basing this release on its Component Object Model (COM). With Visual Basic 4.0, a new type of object, often referred to as a COM or ActiveX control or object was defined. A COM or ActiveX control is basically a component program object based on Microsoft""s COM technologies, which can issue or raise events. With Visual Basic 4.0 and later releases, a developer similarly uses a forms layout package to drag and drop one or more ActiveX controls onto a form window. In addition, by double-clicking an ActiveX control on the form window, a code window is displayed. Inside this code window, the developer may insert text-based programming code to handle the events raised by the respective ActiveX control (i.e., an event handler). This code must comply with the syntactical and keyword constraints defined by Visual Basic in order for it to be properly executed at application run-time. By writing these event handlers, a developer can cause various ActiveX controls to share information and otherwise interact with each other greatly facilitating the creation of application programs.
FIG. 1 illustrates a conventional Visual Basic work space 100 that may be displayed on a computer screen. The work space 100 includes a Form window 102 and a tool palette 104. The tool palette 104 contains a plurality of icons, which represent individual controls, including a vertical scroll control 106 and a text label control 108, among others. A developer may select any of the controls contained on palette 104 to cause the selected control to appear on the Form window 102. By selecting the vertical scroll icon 106, for example, a corresponding vertical scroll image 110 is displayed on the Form window 102. A text label image 112 may be placed on the Form window 102 in a similar manner. At this point, however, there is no inter-relationship between the objects corresponding to vertical scroll image 110 and text label image 112. In order to establish some such relationship (e.g., causing the text label to display the current position of the vertical scroll), the developer must write a subroutine (e.g., an event handler). Each line or statement of the subroutine, moreover, must conform to the syntax and keyword commands of the underlying programming language (e.g., Visual Basic). Specifically, the developer selects the vertical scroll 110, thereby causing a code window 114 to be displayed on screen 100. Inside the code window 144, the developer writes a text-based subroutine 116 that causes the output of the vertical scroll 110 to be displayed in the text label 112.
When this program is subsequently run, images for the vertical scroll bar 110 and the text label 112 will appear on the screen of the user as part of a user interface. The text label 110, moreover, will display the position of the vertical scroll bar 110 (e.g., xe2x80x9c2256xe2x80x9d). If the user moves the slider bar of the vertical scroll, the contents of text label change to display the scroll bar""s new position (e.g., xe2x80x9c3891xe2x80x9d). As shown, with Visual Basic, the developer need not xe2x80x9cwritexe2x80x9d any code to cause the vertical scroll bar image 110 or the text label image 112 to be displayed on the computer screen during run time. In addition, during the programming phase, the developer may move and re-size these user interface elements simply by manipulating their appearance on the Form window 102 (e.g., with a mouse) in a conventional manner. Due to the relative ease with which application programs having user interface elements can be created, Visual Basic has become a highly popular programming tool. However, in order to develop a meaningful application program (i.e., one in which there is some inter-relationship between the user interface elements), the developer must write, in a text-based format, one or more subroutines.
Thus, the developer must learn and is limited by the syntax and keyword structures of Visual Basic.
In addition to Visual Basic and its related products (e.g., Visual C++, etc.), several companies have created software development tools that are almost entirely visually oriented. That is, using these tools, a developer can create an executable application program without having to write a single line of text-based code. For example, National Instruments Corporation of Austin, Tex. has created a programming tool called Lab-VIEW(trademark) for creating virtual instruments primarily for use in the instrumentation industry. Hewlett Packard Company of Palo Alto, Calif. has similarly created a programming tool called HP VEE for generating software programs for use in the electronic testing and data acquisition industries.
HP VEE provides a work area in which a developer can create a data flow diagram. The developer typically selects the objects for inclusion in his or her program from a pull-down menu. HP VEE provides a fixed number of these objects which have been tailored to provide functionality commonly used in the data acquisition industry. The developer may then xe2x80x9cdrawxe2x80x9d data lines between these objects in the work area to form a data flow diagram. In response to drawing these lines, HP VEE creates program steps that transfer data or other information between the respective objects. The developer must perform all of this graphically within the work area.
For developers working in the data acquisition field, HP VEE is a useful programming tool. There are some disadvantages nonetheless. For example, within the data flow diagram, a developer may xe2x80x9cdrawxe2x80x9d multiple data lines from a given pin of an object, thereby creating a branch or fork in the data flow diagram each having their own stream. At some subsequent object in the data flow diagram, the two branches of this fork may merge. The program steps corresponding to these two branches will typically be executed in some particular order. That is, the steps are generally not executed in parallel. Such serial execution can cause problems if the object at which the two streams merge executes in response to new data or information from only one stream. For example, by executing when only part of its input data has been up-dated, the object, and thus the application program in which it is incorporated may generate or otherwise produce unintended results.
Briefly, the invention relates to a method for running application programs that are based upon corresponding graphical flow diagrams which may include one or more forks or branches disposed therein. The flow diagrams are preferably formed by interconnecting a plurality of symbolic representations, that correspond to instances of various program objects, with one or more wire constructs. At least some of the program objects have input properties and are configured to execute an associated function based on the values of these input properties. The flow diagram logically represents the flow of information among the program objects in order to set their input properties. According to the invention, the method first invalidates the input properties of the program objects. Next, the flow diagram or at least a portion thereof is permitted to pass information among the respective program objects, thereby setting their input properties. The program objects are specially configured such that by setting an input property that property is also validated. The program objects are further configured to block execution of their associated functions until all input properties have been validated. Accordingly, program objects are prevented from executing based on stale or improper data caused by the presence of one or more forks or branches within the flow diagram.
In a further aspect of the invention, each wire construct may be configured to maintain information identifying the program objects that it interconnects. The wire constructs then compare this information to determine whether two or more wire constructs emanate from the same symbolic representation. If so, the respective wire constructs is conclude that they are located at a fork or branch of the corresponding flow diagram. In this case, the method only invalidates the input properties of those program objects whose corresponding symbolic representations are located along the streams of the identified fork or branch.